home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.20010306-20010921 / 000247_keithuse@synco_pator.com_Fri Jul 6 09:50:31 EDT 2001.msg < prev    next >
Text File  |  2020-01-01  |  6KB  |  141 lines

  1. Article: 12572 of comp.protocols.kermit.misc
  2. Path: newsmaster.cc.columbia.edu!panix!howland.erols.net!newsfeed.direct.ca!look.ca!newsfeed1.earthlink.net!newsfeed.earthlink.net!newsmaster1.prod.itd.earthlink.net!newsread1.prod.itd.earthlink.net.POSTED!not-for-mail
  3. Newsgroups: comp.protocols.kermit.misc
  4. From: keithuse@synco_pator.com (Keith Doyle) 
  5. Subject: Re: Any way to alter Kermit "quit" so I don't have to "kill?"
  6. References: <h_417.5247$oa1.534611@newsread1.prod.itd.earthlink.net> <9i2n2o$dgn$1@newsmaster.cc.columbia.edu>
  7. Reply-To: keithuse@synco_pator.com (Keith Doyle)
  8. Organization: Rexx Electronic Communications
  9. X-Newsreader: trn 4.0-test74 (May 26, 2000)
  10. Lines: 121
  11. Message-ID: <ORb17.6797$oa1.654216@newsread1.prod.itd.earthlink.net>
  12. Date: Fri, 06 Jul 2001 05:17:34 GMT
  13. NNTP-Posting-Host: 207.167.89.8
  14. X-Complaints-To: abuse@earthlink.net
  15. X-Trace: newsread1.prod.itd.earthlink.net 994396654 207.167.89.8 (Thu, 05 Jul 2001 22:17:34 PDT)
  16. NNTP-Posting-Date: Thu, 05 Jul 2001 22:17:34 PDT
  17. X-Received-Date: Thu, 05 Jul 2001 22:15:20 PDT (newsmaster1.prod.itd.earthlink.net)
  18. Xref: newsmaster.cc.columbia.edu comp.protocols.kermit.misc:12572
  19.  
  20.  
  21. In article <9i2n2o$dgn$1@newsmaster.cc.columbia.edu>,
  22. Frank da Cruz <fdc@watsun.cc.columbia.edu> wrote:
  23. >In article <h_417.5247$oa1.534611@newsread1.prod.itd.earthlink.net>,
  24. >Keith Doyle <keithuse@synco_pator.com> wrote:
  25. >: 
  26. >: Now my original approach used lrz something like the following:
  27. >: 
  28. >:     lrz </dev/modem >/dev/modem
  29. >: 
  30. >: Since this doesn't hang up the line, I presume that the issue is NOT
  31. >: "close" of the device.
  32. >: 
  33. >Right -- it uses the open stdin/stdout file descriptors, which have
  34. >been redirected from/to the modem.  Since the lrz program uses stdin/out,
  35. >it never opens or closes it.
  36.  
  37.  
  38. Though the shell does-- and that doesn't cause a disconnect.
  39.  
  40. Also, neither does this simple C program, run in place of the
  41. kermit or lrz/lsz, so I'm inclined to doubt it's the close that's 
  42. responsible for the disconnect:
  43. --------------------------------------------------------------
  44. #include <stdio.h>
  45. #include <fcntl.h>
  46.  
  47. main()
  48. {
  49. int d;
  50.     d = open("/dev/modem",O_RDWR);
  51.     sleep(4);
  52.     close(d);
  53.     exit (0);
  54. }
  55. --------------------------------------------------------------
  56.  
  57.  
  58.  
  59. >: So I tried serveral things.  I noticed that it is possible to pass in
  60. >: an open file descriptor and have kermit use that.  But, I gathered
  61. >: you can't just do:
  62. >: 
  63. >:     kermit -r -i -l 0 </dev/modem
  64. >: 
  65. >: As this is only open for input, and kermit is going to need bidirectional
  66. >: I/O on the FD.
  67. >:
  68. >Did you try it?
  69.  
  70. Yes, with no success.  It never seemed to negotiate with the other end
  71. and start the transfer.  I'll have to report back on more specific details 
  72. when I try it again...
  73.  
  74. >: So lastly, I figured ok, let's see if it really is the close of the
  75. >: device or something *specific* kermit is doing on exit.  I manually
  76. >: invoked kermit so that it wouldn't exit, and instead of doing a "quit"
  77. >: after the transfer, I switched to another window and did a kill -9
  78. >: on the kermit process.  Voila!  no disconnect occurred.
  79. >: 
  80. >Because you killed Kermit and it couldn't close the device.  Meanwhile 
  81. >another process had it open, right?  That's why you didn't carrier drop
  82. >or whatever.
  83.  
  84. Even on a kill of that sort, Unix does the close, I believe.
  85. And as noted, the C test program specifically closes and that doesn't 
  86. cause a disconnect.  You can try something similar yourself, using
  87. another kermit process itself to simulate my driver program:
  88.  
  89.  
  90. 1. From a unix box, Start a kermit session on a modem, and dial a system
  91. 2. escape to the command line
  92. 3. shell out
  93. 4. run my little test program on the apropriate /dev  (/dev/modem in my
  94.    case).  Note no disconnect.
  95.  
  96. 5. Remove the kermit lock file (only so you can run a second kermit on the port)
  97. 6. run a second kermit (from the original kermit shell-out) on the same /dev and 
  98.    then just do a quit.
  99.  
  100. 7. Kermit will warn you there may be an active connection, and ask you if
  101.    you still want to exit.  Your choice is to either not-exit or say yes
  102.    you want to exit at which point it disconnects the line.  I believe if
  103.    it just did a "close" and then an "exit" here things would be ok, but
  104.    more is going on.
  105.  
  106.  
  107. >Try the first method (-l 0) and see what happens.  If that doesn't work,
  108. >what I'd recommend is to let Kermit handle everything -- dialing, terminal
  109. >session, and file transfer.  That's what it's designed for.
  110.  
  111. That may be what it's designed for, but I already have an exceedingly
  112. complex program that originally used zmodem that I'm not going to rewrite
  113. from scratch in a specialized script language I would have to learn 
  114. special for that one purpose, when all I need is something that 
  115. implements the protocol without mucking with the connection-- I just want 
  116. to plug in a replacement protocol without rewriting the whole schmeer.
  117. "kermit -r -i -l 0 </dev/modem" would be great if I can get it or something
  118. like it to work-- so far I haven't had any luck getting it to transfer...
  119.  
  120.  
  121. >In any case, let us know what happens and we'll see what to do next.
  122.  
  123. If there's a way to make the FD approach work, it's worth investigating
  124. further.  I presume it should work, but there's something I must not be doing
  125. right to set it up.  I'll try it a little more and report back more specific 
  126. on what I tried and how it acts.  Thanks for the response-- I do get the idea 
  127. that kermit in general is a far more sophisticated program than zmodem 
  128. (certainly way more robust a protocol) but I must admit I rather like the 
  129. modularity of keeping the protocol separate from the scripting...
  130.  
  131.  
  132.  
  133.  
  134. --
  135.  
  136. Keith Doyle      <http://www.syncopator.com/carousel>
  137. (to send me an E-letter, remove underbars in reply address)
  138.  
  139. "Simple ain't easy."  -- Thelonious Monk
  140.  
  141.